Errata-1 Printing 



Note: The following errata only pertain to the first printing of the PMBOK® Guide — Fifth Edition. In order to verify the 
print run of your book (or PDF), refer to the bottom of the copyright page (which precedes the Notice page and Table of 
Contents). The last numeral in the string beginning "1 0 9 8" etc. denotes the printing of that particular copy. 

Minor editorial changes have been made to the text and figures. Notable corrections are listed below. 



Page Correction 

60 Section 3.9 (1 st paragraph) — Corrected the Knowledge Areas listed to include Project Cost Management 

1 33 Figure 5-1 5 — Corrected the output for "8.3 Control Quality" to read "verified deliverables" 

177 Figure 6-18 — Added the following clarifying note to the figure: "This example uses the accepted 

convention of the project starting on day 1 for calculating calendar start and finish dates. There are other 
accepted conventions that may be used." 

1 96 Figure 7-3 — Changed 6.2 Define Activities to the correct process of 7.2 Estimate Costs and changed 6.3 

Sequence Activities to the correct process of 7.3 Determine Budget. 

230 Figure 8-1 — Corrected the output for 8.3.3.3 to read "verified deliverables" 

31 7 Figure 1 1 -4 — Inserted the correct graphic for an example of a risk breakdown structure 

320 Figure 1 1 -6 — Modified this figure to show that the "risk register" is also an input to the following 

processes: 6.4 Estimate Activity Resources, 6.5 Estimate Activity Durations, 6.6 Develop Schedule, and 
7.3 Determine Budget 

483 PMBOK Guide - Fifth Edition Core Committee — Corrected the listing to include the following members: 

George Jucan, MSc, PMP (Sections 9, 10, and 13 Lead); Clifford W. Sprague, PMP (Communications) 

566 Included the definition for verified deliverables in the Glossary 



Errata-2 na Printing 



Note: The following errata only pertain to the second printing of the PMBOK® Guide — Fifth Edition. In order to verify 
the print run of your book (or PDF), refer to the bottom of the copyright page (which precedes the Notice page and 
Table of Contents). The last numeral in the string beginning "10 9 8" etc. denotes the printing of that particular copy. 

Minor editorial changes have been made to the text and figures. Notable corrections are listed below. 
Page Correction 

Cover The ANSI designation on the cover is incorrect. The correct designation is ANSI/PMI 99-001 -201 3. 

10 Section 1 .4.3 — The following two paragraphs were inadvertently omitted at the end of this section: 

Projects, within programs or portfolios, are a means of achieving organizational goals and objectives, 
often in the context of a strategic plan. Although a group of projects within a program can have discrete 
benefits, they can also contribute to the benefits of the program, to the objectives of the portfolio, and to 
the strategic plan of the organization. 

Organizations manage portfolios based on their strategic plan. One goal of portfolio management is to 
maximize the value of the portfolio through careful examination of its components — the constituent 
programs, projects, and other related work. Those components contributing the least to the portfolio's 
strategic objectives may be excluded. In this way, an organization's strategic plan becomes the primary 
factor guiding investments in projects. At the same time, projects provide feedback to programs and 
portfolios by means of status reports, lessons learned, and change requests that may help to identify 
impacts to other projects, programs, or portfolios. The needs of the projects, including the resource 
needs, are rolled up and communicated back to the portfolio level, which in turn sets the direction for 
organizational planning. 

74 Section 4.2.1 .1 — Change the last sentence in this section to read as follows: 

The project team uses the project charter as a starting point for initial project planning. 
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Portfolio management refers to the centralized management of one or more portfolios to achieve strategic 
objectives. Portfolio management focuses on ensuring that projects and programs are reviewed to prioritize 
resource allocation, and that the management of the portfolio is consistent with and aligned to organizational 
strategies. 

1 .4.3 Projects and Strategic Planning 

Projects are often utilized as a means of directly or indirectly achieving objectives within an organization's 
strategic plan. Projects are typically authorized as a result of one or more of the following strategic considerations: 

• Market demand (e.g., a car company authorizing a project to build more fuel-efficient cars in response 
to gasoline shortages); 

• Strategic opportunity/business need (e.g., a training company authorizing a project to create a new 
course to increase its revenues); 

• Social need (e.g., a nongovernmental organization in a developing country authorizing a project to provide 
potable water systems, latrines, and sanitation education to communities suffering from high rates of 
infectious diseases); 

• Environmental consideration (e.g., a public company authorizing a project to create a new service for 
electric car sharing to reduce pollution); 

• Customer request (e.g., an electric utility authorizing a project to build a new substation to serve a new 
industrial park); 

• Technological advance (e.g., an electronics firm authorizing a new project to develop a faster, cheaper, and 
smaller laptop based on advances in computer memory and electronics technology); and 

• Legal requirement (e.g., a chemical manufacturer authorizing a project to establish guidelines for proper 
handling of a new toxic material). 

Projects, within programs or portfolios, are a means of achieving organizational goals and objectives, often in 
the context of a strategic plan. Although a group of projects within a program can have discrete benefits, they can 
also contribute to the benefits of the program, to the objectives of the portfolio, and to the strategic plan of the 
organization. 

Organizations manage portfolios based on their strategic plan. One goal of portfolio management is to maximize 
the value of the portfolio through careful examination of its components — the constituent programs, projects, and 
other related work. Those components contributing the least to the portfolio's strategic objectives may be excluded. 
In this way, an organization's strategic plan becomes the primary factor guiding investments in projects. At the 
same time, projects provide feedback to programs and portfolios by means of status reports, lessons learned, 
and change requests that may help to identify impacts to other projects, programs, or portfolios. The needs of the 
projects, including the resource needs, are rolled up and communicated back to the portfolio level, which in turn 
sets the direction for organizational planning. 
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1 .4.4 Project Management Office 

A project management office (PMO) is a management structure that standardizes the project-related governance 
processes and facilitates the sharing of resources, methodologies, tools, and techniques. The responsibilities of a 
PMO can range from providing project management support functions to actually being responsible for the direct 
management of one or more projects. 

There are several types of PMO structures in organizations, each varying in the degree of control and influence 
they have on projects within the organization, such as: 

• Supportive. Supportive PMOs provide a consultative role to projects by supplying templates, best 
practices, training, access to information and lessons learned from other projects. This type of PMO 
serves as a project repository. The degree of control provided by the PMO is low. 

• Controlling. Controlling PMOs provide support and require compliance through various means. 
Compliance may involve adopting project management frameworks or methodologies, using specific 
templates, forms and tools, or conformance to governance. The degree of control provided by the PMO 
is moderate. 

• Directive. Directive PMOs take control of the projects by directly managing the projects. The degree of 
control provided by the PMO is high. 

The PMO integrates data and information from corporate strategic projects and evaluates how higher level 
strategic objectives are being fulfilled. The PMO is the natural liaison between the organization's portfolios, 
programs, projects, and the corporate measurement systems (e.g. balanced scorecard). 

The projects supported or administered by the PMO may not be related, other than by being managed together. 
The specific form, function, and structure of a PMO are dependent upon the needs of the organization that it 
supports. 

A PMO may have the authority to act as an integral stakeholder and a key decision maker throughout the life 
of each project, to make recommendations, or to terminate projects or take other actions, as required, to remain 
aligned with the business objectives. In addition, the PMO may be involved in the selection, management, and 
deployment of shared or dedicated project resources. 

A primary function of a PMO is to support project managers in a variety of ways which may include, but are not 
limited to: 

• Managing shared resources across all projects administered by the PMO; 

• Identifying and developing project management methodology, best practices, and standards; 

• Coaching, mentoring, training, and oversight; 

• Monitoring compliance with project management standards, policies, procedures, and templates by means 
of project audits; 

• Developing and managing project policies, procedures, templates, and other shared documentation 
(organizational process assets); and 
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3 - PROJECT MANAGEMENT PROCESSES 



3.9 Role of the Knowledge Areas 

The 47 project management processes identified in the PMBOK® Guide are further grouped into ten separate 
Knowledge Areas. A Knowledge Area represents a complete set of concepts, terms, and activities that make up 
a professional field, project management field, or area of specialization. These ten Knowledge Areas are used on 
most projects most of the time. Project teams should utilize these ten Knowledge Areas and other Knowledge Areas, 
as appropriate, for their specific project. The Knowledge Areas are: Project Integration Management, Project Scope 
Management, Project Time Management, Project Cost Management, Project Quality Management, Project Human 
Resource Management, Project Communications Management, Project Risk Management, Project Procurement 
Management and Project Stakeholder Management. Each Knowledge Area within the PMBOK 11 ' Guide is contained 
in a separate section. 

The PMBOK® Guide defines the important aspects of each Knowledge Area and how it integrates with the 
five Process Groups. As supporting elements, the Knowledge Areas provide a detailed description of the process 
inputs and outputs along with a descriptive explanation of tools and techniques most frequently used within the 
project management processes to produce each outcome. A data flow diagram is provided in each Knowledge 
Area (Sections 4 through 1 3). The data flow diagram is a summary level depiction of the process inputs and process 
outputs that flow down through all the processes within a specific Knowledge Area (see Figure 3-6 for data flow 
diagram legend). Although the processes are presented here as discrete elements with well-defined interfaces, in 
practice they are iterative and can overlap and interact in ways not detailed here. 

Table 3-1 reflects the mapping of the 47 project management processes within the 5 Project Management 
Process Groups and the 1 0 Knowledge Areas. 



Process outside of 
Knowledge Area 




External to a Process 



Processes within a 
Knowledge Area 

► Inter-knowledge area relationships 

► Extra-knowledge area relationships 

Process flow 



The data flow diagrams show basic steps and interactions. Many additional interactions are possible. 



Figure 3-6. Data Flow Diagram Legend 
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4 - PROJECT INTEGRATION MANAGEMENT 



The project management plan defines how the project is executed, monitored and controlled, and closed. The 
project management plan's content varies depending upon the application area and complexity of the project. It 
is developed through a series of integrated processes extending through project closure. This process results in 
a project management plan that is progressively elaborated by updates, and controlled and approved through the 
Perform Integrated Change Control (Section 4.5) process. Projects that exist in the context of a program should 
develop a project management plan that is consistent with the program management plan. For example, if the 
program management plan indicates all changes exceeding a specified cost need to be reviewed by the change 
control board (CCB), then this process and cost threshold needs to be defined in the project management plan. 

4.2.1 Develop Project Management Plan: Inputs 

4.2.1.1 Project Charter 

Described in Section 4.1.3.1. The size of the project charter varies depending on the complexity of the 
project and the information known at the time of its creation. At a minimum, the project charter should define 
the high-level boundaries of the project. The project team uses the project charter as the starting point for 
initial planning throughout the Initiating Process Group. 

4.2.1 .2 Outputs from Other Processes 

Outputs from many of the other processes described in Sections 5 through 13 are integrated to create the 
project management plan. Any baselines and subsidiary plans that are an output from other planning processes 
are inputs to this process. In addition, changes to these documents may necessitate updates to the project 
management plan. 

4.2.1 .3 Enterprise Environmental Factors 

Described in Section 2.1.5. The enterprise environmental factors that can influence the Develop Project 
Management Plan process include, but are not limited to: 

• Governmental or industry standards; 

• Project management body of knowledge for vertical market (e.g., construction) and/or focus area 
(e.g. environmental, safety, risk, or agile software development); 

• Project management information system (e.g., an automated tool, such as a scheduling software tool, a 
configuration management system, an information collection and distribution system, or web interfaces 
to other online automated systems); 
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5.5 Validate Scope 

Validate Scope is the process of formalizing acceptance of the completed project deliverables. The key benefit 
of this process is that it brings objectivity to the acceptance process and increases the chance of final product, 
service, or result acceptance by validating each deliverable. The inputs, tools and techniques, and outputs of this 
process are depicted in Figure 5-14. Figure 5-1 5 depicts the data flow diagram of the process. 
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.1 Project management plan 
.2 Requirements 
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Figure 5-14. Validate Scope: Inputs, Tools & Techniques, and Outputs 
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Figure 5-15. Validate Scope Data Flow Diagram 
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6 - PROJECT TIME MANAGEMENT 



On any network path, the schedule flexibility is measured by the amount of time that a schedule activity can 
be delayed or extended from its early start date without delaying the project finish date or violating a schedule 
constraint, and is termed "total float." A CPM critical path is normally characterized by zero total float on the 
critical path. As implemented with PDM sequencing, critical paths may have positive, zero, or negative total 
float depending on constraints applied. Any activity on the critical path is called a critical path activity. Positive 
total float is caused when the backward pass is calculated from a schedule constraint that is later than the 
early finish date that has been calculated during forward pass calculation. Negative total float is caused when a 
constraint on the late dates is violated by duration and logic. Schedule networks may have multiple near-critical 
paths. Many software packages allow the user to define the parameters used to determine the critical path(s). 
Adjustments to activity durations (if more resources or less scope can be arranged), logical relationships (if the 
relationships were discretionary to begin with), leads and lags, or other schedule constraints may be necessary 
to produce network paths with a zero or positive total float. Once the total float for a network path has been 
calculated, then the free float — the amount of time that a schedule activity can be delayed without delaying the 
early start date of any successor or violating a schedule constraint— can also be determined. For example the 
free float for Activity B, in Figure 6-18, is 5 days. 



1 


5 


5 


A 


1 


0 


5 



6 


5 


10 


B 


11 


5 


15 



6 


10 


15 


C 


6 


0 


15 



r 



Path A-B-D - 25 



NOTE: This example uses the accepted convention of the project 
starting on day 1 for calculating calendar start and finish dates. 
There are other accepted conventions that may be used. 



16 


15 


30 


D 


16 


0 


30 



.0 



Path A-C-D = 30 
(Critical Path) 



KEY Activity 
Node 



Early 
Start 


Duration 


Early 
Finish 


Activity Name 


Late 
Start 


Total 
Float 


Late 
Finish 



Critical Path Link 
Non-Critical Path Link 



Figure 6-18. Example of Critical Path Method 
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Figure 7-3. Plan Cost Management: Data Flow Diagram 

The cost management processes and their associated tools and techniques are documented in the cost 
management plan. The cost management plan is a component of the project management plan. 



7.1.1 Plan Cost Management: Inputs 

7.1 .1 .1 Project Management Plan 

Described in Section 4.2.3.1. The project management plan contains information used to develop the cost 
management plan, which contains, but is not limited to: 

• Scope baseline. The scope baseline includes the project scope statement and WBS detail for cost 
estimation and management. 

• Schedule baseline. The schedule baseline defines when the project costs will be incurred. 

• Other information. Other cost-related scheduling, risk, and communications decisions from the project 
management plan. 
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Project Quality 
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8.3 Control Quality 
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-1 . Project Quality Management Overview 
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11 - PROJECT RISK MANAGEMENT 



• Risk categories. Provide a means for grouping potential causes of risk. Several approaches can be 
used, for example, a structure based on project objectives by category. A risk breakdown structure (RBS) 
helps the project team to look at many sources from which project risk may arise in a risk identification 
exercise. Different RBS structures will be appropriate for different types of projects. An organization can 
use a previously prepared custom categorization framework, which may take the form of a simple list of 
categories or may be structured into an RBS. The RBS is a hierarchical representation of risks according 
to their risk categories. An example is shown in Figure 1 1 -4. 




i 

Technical 



2 

External 



1.1 

Requirements 



1.2 
Technology 



1.3 

Complexity and 
Interfaces 



1.4 

Performances 
and Reliability 



1.5 
Quality 



Organizational 



2.1 

Subcontractors 
and Suppliers 



2.2 
Regulatory 



2.3 

Market 



2.4 
Customer 




3.1 
Project 
Dependencies 



3.2 

Resources 



3.3 
Funding 



3.4 
Prioritization 



2.5 
Weather 



4 

Project 



4.1 

Estimating 



4.2 
Planning 



4.3 

Controlling 



4.4 

Communication 



Figure 11-4. Example of a Risk Breakdown Structure (RBS) 

• Definitions of risk probability and impact. The quality and credibility of the risk analysis requires that 
different levels of risk probability and impact be defined that are specific to the project context. General 
definitions of probability levels and impact levels are tailored to the individual project during the Plan 
Risk Management process for use in subsequent processes. Table 11-1 is an example of definitions of 
negative impacts that could be used in evaluating risk impacts related to four project objectives. (Similar 
tables may be established with a positive impact perspective). Table 11-1 illustrates both relative and 
numerical (in this case, nonlinear) approaches. 
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Figure 11-6. Identify Risks Data Flow Diagram 
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APPENDIX X2 

CONTRIBUTORS AND REVIEWERS OF 
THE PMBOK® GUIDE— FIFTH EDITION: 

PMI volunteers first attempted to codify the Project Management Body of Knowledge in the Special Report 
on Ethics, Standards, and Accreditation, published in 1983. Since that time, other volunteers have come forward 
to update and improve that original document and contribute to this globally recognized standard for project 
management, PMI's A Guide to the Project Management Body of Knowledge {PMBOK® Guide). This appendix lists, 
alphabetically within groupings, those individuals who have contributed to the development and production of the 
PMBOK® Guide - Fifth Edition. No simple list or even multiple lists can adequately portray all the contributions of 
those who have volunteered to develop the PMBOK® Guide - Fifth Edition. 

The Project Management Institute is grateful to all of these individuals for their support and acknowledges their 
contributions to the project management profession. 

X2.1 PMBOK® Guide— Fifth Edition Core Committee 

The following individuals served as members, were contributors of text or concepts, and served as leaders 
within the Project Core Committee: 

Dave Violette, MPM, PMP, Chair 

Joseph W. Kestel, PMP, Vice Chair 

Nick Clemens, PMP (Sections 3 and 4 Lead) 

Dan Deakin, PMP (Sections 11 and 12 Lead) 

Theofanis C. Giotis, PMP, PMI-ACP (Sections 1 and 2 Lead) 

Marie A. Gunnerson, (Sections 6 and 7 Lead) 

George Jucan, MSc, PMP (Sections 9, 10, and 13 Lead) 

Vanina Mangano, PMP, PMI-RMP (Integrated Content and Change Control Lead) 

Mercedes Martinez Sanz, PMP (Sections 5 and 8 Lead) 

Carolina Gabriela Spindola, PMP, SSBB (Quality Control Lead) 

Clifford W. Sprague, PMP (Communications) 

Kristin L. Vitello, CAPM, Standards Project Specialist 
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GLOSSARY 



Trend Analysis. An analytical technique that uses mathematical models to forecast future outcomes based on 
historical results. It is a method of determining the variance from a baseline of a budget, cost, schedule, or scope 
parameter by using prior progress reporting periods' data and projecting how much that parameter's variance from 
baseline might be at some future point in the project if no changes are made in executing the project. 

Trigger Condition. An event or situation that indicates that a risk is about to occur. 

Unanimity. Agreement by everyone in the group on a single course of action. 

Validate Scope. The process of formalizing acceptance of the completed project deliverables. 

Validation. The assurance that a product, service, or system meets the needs of the customer and other identified 
stakeholders. It often involves acceptance and suitability with external customers. Contrast with verification. 

Value Engineering. An approach used to optimize project life cycle costs, save time, increase profits, improve 
quality, expand market share, solve problems, and/or use resources more effectively. 

Variance. A quantifiable deviation, departure, or divergence away from a known baseline or expected value. 

Variance Analysis. A technique for determining the cause and degree of difference between the baseline and 
actual performance. 

Variance at Completion (VAC). A projection of the amount of budget deficit or surplus, expressed as the 
difference between the budget at completion and the estimate at completion. 

Variation. An actual condition that is different from the expected condition that is contained in the baseline plan. 

Velocity. A measure of a team's productivity rate at which the deliverables are produced, validated, and 
accepted within a predefined interval. Velocity is a capacity planning approach frequently used to forecast 
future project work. 

Verification. The evaluation of whether or not a product, service, or system complies with a regulation, requirement, 
specification, or imposed condition. It is often an internal process. Contrast with validation. 

Verified Deliverables. Completed project deliverables that have been checked and confirmed for correctness 
through the Control Quality process. 

Voice of the Customer. A planning technique used to provide products, services, and results that truly reflect 
customer requirements by translating those customer requirements into the appropriate technical requirements for 
each phase of project product development. 
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